Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-083

Text File | 1995-12-31 | 120KB | 3,132 lines

C.S.M.P. Digest             Mon, 13 Feb 95       Volume 3 : Issue 83

Today's Topics:

        (silly?) Question about "Print" apple event
        A "better" Random()
        Any speedup tips for this?
        Getting an event outside of the Main Loop
        Help a dumb father help his son with Mac programming
        How can I tell if a driver (eg MacTCP) is open
        Quality of Random()
        Tip Of the Month: Transparent PICTs
        True RANDOM numbers, (was Re: Quality of Random())



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (David Shaw)
Subject: (silly?) Question about "Print" apple event
Date: Sun, 22 Jan 1995 15:21:41 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

I am sure this question has come up time and again, but what are you
supposed to do to implement the _required_ four Apple Events, when one or
more of them really doesn't apply to your application?  For instance, I am
working on a text filtering program which has no print function, and so
the print event makes very little sense.  Should I just not provide a
handler for it (which seems to contravene the idea of the four _required_
functions), provide a handler that does nothing (i.e. just returns with
no error), or perhaps return an EventNotHandled?

David

--
  David Shaw | [e-mail] | WWW http://hertz.njit.edu/~dms1070
+--------------------------------------------------------------------------+
  "There are two major products that come out of Berkeley: LSD and UNIX.
     We don't believe this to be a coincidence." - Jeremy S. Anderson

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Sun, 22 Jan 1995 14:01:18 -0500
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer.help: 22-Jan-95 (silly?)
Question about "Pr.. David [e-mail] (869)

> I am sure this question has come up time and again, but what are you
> supposed to do to implement the _required_ four Apple Events, when one or
> more of them really doesn't apply to your application?  For instance, I am
> working on a text filtering program which has no print function, and so
> the print event makes very little sense.  Should I just not provide a
> handler for it (which seems to contravene the idea of the four _required_
> functions), provide a handler that does nothing (i.e. just returns with
> no error), or perhaps return an EventNotHandled?

If the application never generates any files (of its creator), then it
should never receive a Print event. In that case, I would have a handler
that puts up an error dialog ("This program cannot print anything, and
how the hell did you get here, anyway?")

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Mon, 23 Jan 1995 17:18:11 +1300
Organization: University of Waikato

In article <[e-mail]>, "Andrew C. Plotkin"
<[e-mail]> wrote:

>If the application never generates any files (of its creator), then it
>should never receive a Print event. In that case, I would have a handler
>that puts up an error dialog ("This program cannot print anything, and
>how the hell did you get here, anyway?")

You can get there via AppleScript:

    tell application "Duh" to print file "SomebodyElsesDoc"

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sun, 22 Jan 1995 19:24:41 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (David Shaw) wrote:

> I am sure this question has come up time and again, but what are you
> supposed to do to implement the _required_ four Apple Events, when one or
> more of them really doesn't apply to your application?  For instance, I am
> working on a text filtering program which has no print function, and so
> the print event makes very little sense.  Should I just not provide a
> handler for it (which seems to contravene the idea of the four _required_
> functions), provide a handler that does nothing (i.e. just returns with
> no error), or perhaps return an EventNotHandled?

I return an errAEEventNotHandled (because I haven't handled it, for those
I don't handle).  Finder doesn't seem to care...other apps may, and the
errAEEventNotHandled gives some hypothetical system handler for the event
a chance (if you're sure you DON'T want somebody's system handler to see
the event, return noErr, I suppose).

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Mon, 23 Jan 1995 12:30:47 +1300
Organization: University of Waikato

In article <[e-mail]>,
[e-mail] (David Shaw) wrote:

>I am sure this question has come up time and again, but what are you
>supposed to do to implement the _required_ four Apple Events, when one or
>more of them really doesn't apply to your application?  For instance, I am
>working on a text filtering program which has no print function, and so
>the print event makes very little sense.  Should I just not provide a
>handler for it (which seems to contravene the idea of the four _required_
>functions), provide a handler that does nothing (i.e. just returns with
>no error), or perhaps return an EventNotHandled?

Those two choices are equivalent in terms of their behaviour to the user.
If your application doesn't print, then don't provide a print handler. I
have released several AppleEvent-aware applications that don't print, and
this is what I do in all of them.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
"So that's who Captain Bipto was. If only Lawrence had known..."

+++++++++++++++++++++++++++

>From [e-mail] (Dave Polaschek)
Date: Tue, 24 Jan 1995 09:35:51 -0600
Organization: LaserMaster

In article <[e-mail]>,
[e-mail] (David Shaw) wrote:
> ...
> Should I just not provide a
> handler for it (which seems to contravene the idea of the four _required_
> functions), provide a handler that does nothing (i.e. just returns with
> no error), or perhaps return an EventNotHandled?

Seems to me that returning EventNotHandled is the most accurate reply you
can give. That's how I've dealt with this when I was faced with the same
problem. Having no handler for the PDOC will probably make some scripting
app mad at you in the future, so putting it in and just having it return
EventNotHandled seems safest.

OTOH, in an app I have whose sole function is to print documents, sending
an ODOC and a PDOC both end up in the same handler.

-DaveP
--
Dave Polaschek -- work:[e-mail] -- home:[e-mail]
"Gentlemen! You can't fight in here. This is the War Room."
                                                  -- Dr. Strangelove

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Thu, 26 Jan 1995 17:15:13 +1300
Organization: University of Waikato

In article <[e-mail]>, [e-mail]
(Dave Polaschek) wrote:

>In article <[e-mail]>,
>[e-mail] (David Shaw) wrote:
>> ...
>> Should I just not provide a
>> handler for it (which seems to contravene the idea of the four _required_
>> functions), provide a handler that does nothing (i.e. just returns with
>> no error), or perhaps return an EventNotHandled?
>
>Seems to me that returning EventNotHandled is the most accurate reply you
>can give. That's how I've dealt with this when I was faced with the same
>problem. Having no handler for the PDOC will probably make some scripting
>app mad at you in the future, so putting it in and just having it return
>EventNotHandled seems safest.

But errAEEventNotHandled is the error you get when you don't specify a
handler anyway. Thus, as far as any client application can tell, having no
handler, as opposed to having a handler that does nothing and returns that
error, is the same thing.

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sat, 28 Jan 1995 15:01:11 -0800
Organization: Internet for the Olympic Peninsula

In article <ldo-2601951715130001@130.217.96.144>, [e-mail]
(Lawrence D9Oliveiro) wrote:

> In article <[e-mail]>, [e-mail]
> (Dave Polaschek) wrote:
>
> >In article <[e-mail]>,
> >[e-mail] (David Shaw) wrote:
...
>
> But errAEEventNotHandled is the error you get when you don't specify a
> handler anyway. Thus, as far as any client application can tell, having no
> handler, as opposed to having a handler that does nothing and returns that
> error, is the same thing.

As long as there isn't a '****'/'****' or an 'aevt'/'****' handler lurking
somewhere, not catching Print is the same as catching it and returning the
error.  Doing the explict errEventNotHandled helps guard (I foolishly
wrote "guards" first) against errant Scripting Additions, freeware, or
whatever.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

---------------------------

>From [e-mail] (Robert Mah)
Subject: A "better" Random()
Date: Sat, 28 Jan 1995 02:45:00 -0500
Organization: One Step Beyond

[e-mail] (Aaron Barnett) wrote:

) so has anyone come up with a better random function that they would
) like to post?  Has anyone coded anything from a numerical recepies
) book?

OK, here is some code adapted from the book "Numerical Recepies in C"
which was itself adapted from Knuth.  It uses the subtractive method
instead of the linear congruential method that both Random() and rand()
uses.

It seems to have better of sequential coorelation (i.e. less) and thus
has better k-space distribution.  It is much slower on 68K machines
because it uses floating point.

Don't ask me for support unless you're willing to pay :-).  Besides,
it's would be wiser to buy Numerical Recepies and Knuth instead --
you'll learn more.

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     [phone]
One Step Beyond         and Network Consulting           [e-mail]


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- CUT HERE -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

/*
 * Use RandUniform() to get a random number between 0.0 and 1.0.
 * Use RandSeed() to re-initialize the random number sequence.
 *
 * WARNING: This is NOT a drop-in replacement for Random() or rand()
 */
float RandUniform( void );
void RandSeed( short seed );


/*
 * Knuth says that you can use any really big MBIG and any really big
 * MSEED as long as MSEED < MBIG
 */
#define MBIG    1000000000L
#define MSEED   161803398L
#define MZ      0L
#define FAC     (1.0/MBIG)

static short    inext, inextp;
static long     ma[56];
static short    inited = 0;


/*
 * Returns a uniform random number between 0.0 and 1.0. Unlike Random()
 * and rand(), this is not based on the linear congruential method, it
 * uses the subtractive method instead.
 */
float RandUniform( void )
{
    long v;

    if( inited == false )       // Initialize everything
        RandSeed( 0 );

    if( ++inext == 56 )         // Both indexes need to roll around when
        inext = 1;              // they reach the end of the table.
    if( ++inextp == 56 )
        inextp = 1;

    v = ma[inext] - ma[inextp]; // Generate a new random # subtractively
    if( v < MZ )                // Be sure its in the range
        v += MBIG;

    ma[ inext ] = v;            // Store it.

    return v * FAC;
}


/*
 * Initialize the random number sequence.  Set seed to any negative value
 * to initialize or re-initize the sequence.
 */
void RandSeed( short seed )
{
    short i, ii, k;
    long  mj, mk;

    if( seed > 0 )
        seed = -seed;

    inited = true;

    mj = MSEED - (seed < 0 ? -seed : seed );
    mj %= MBIG;
    ma[55] = mj;
    mk = 1;

    for( i = 1; i <= 54; i++ )
    {
        ii = ( 21 * i ) % 55;
        ma[ii] = mk;
        mk = mj - mk;
        if( mk < MZ )
            mk += MBIG;
        mj = ma[ii];
    }

    for( k = 1; k <= 4; k++ )
    {
        for( i = 1; i <= 55; i++ )
        {
            ma[i] -= ma[ 1 +(i+30) % 55 ];
            if( ma[i] < MZ )
                ma[i] += MBIG;
        }
    }

    inext = 0;
    inextp = 31;
}

// eof

---------------------------

>From [e-mail] (Vince Tourangeau)
Subject: Any speedup tips for this?
Date: Thu, 26 Jan 1995 20:47:04 GMT
Organization: Carleton University


I took the code for direct-to-screen writing from the Mac Programming
FAQ, and sped it up as much as I could. However, I was wondering if
there's anything I can do to speed it up some more. The following code
is what I came up with; it's basically the code from the FAQ with most
of the SetPixel stuff moved outside of the loop. This just turns the
enitire screen black:

void init (void);
void SetPixel ( int, int, unsigned long);
GDHandle theGD ;
char * theScreen ;
long rowBytes ;
short bitsPerPixel ;
PixMapHandle pmh ;
Boolean oldMode ;
Boolean newMode;

void main (void)
{
        char *screen;
        GrafPtr myPort;
        int i,j;
        Point thePoint;
        init ();

        //screen = (qd.thePort)->portBits.baseAddr;

        HideCursor ();

        theGD = GetMainDevice () ;
        pmh = ( * theGD ) -> gdPMap ;
        rowBytes = ( ( * pmh ) -> rowBytes ) & 0x3fff ;
        theScreen = ( char * ) ( * pmh ) -> baseAddr ;
        bitsPerPixel = ( * pmh ) -> pixelSize ;
        oldMode = GetMMUMode ();
        newMode = true32b;
        SwapMMUMode ( & newMode ) ;

        for (i = 0; i < 640; i++) {
                for (j = 0; j < 480; j++) {
                        SetPixel (i, j, 255); // sets all pixels to black
                        }
                }
        SwapMMUMode ( & oldMode ) ;
        ShowCursor ();
}


void init (void)
{
        Rect windowBounds;
        WindowPtr myWindow;
        Rect theRect;
        RGBColor aColor;
        double PI;
        int i;

        InitGraf(&qd.thePort);
        InitFonts();
        InitWindows();
        InitMenus();
        TEInit();
        InitDialogs(nil);
        InitCursor();

        SetRect (&windowBounds, 0, 0, 640, 480);

        myWindow = NewCWindow (nil, &windowBounds, "\p3-D Crap", true,
documentProc, nil, false, 0);
        SetPort (myWindow);

}

void SetPixel ( int h, int v , unsigned long value )
{
        theScreen [v*640+h ] = value ;
}

The thing is, if I call PaintRect (&(*pmh)->bounds), it fills the
screen faster than I can see; using the above code, you can see the
pixels being written to the screen, even on my PowerMac 6100 (and yes,
the code is native). What gives? Any tips on how to speed this up are
much appreciated.
        Vince

- --------------------------------------------------------------------
Flaming Carrot: "Come here and look in the window!"
Herbie: "GADZOOKS! Shakespeare is an AEROBICS INSTRUCTOR!!!"

Vince Tourangeau
Carleton University
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Patrick Stadelmann)
Date: Fri, 27 Jan 1995 14:25:18 +0100
Organization: University of Neuchatel

>
>         for (i = 0; i < 640; i++) {
>                 for (j = 0; j < 480; j++) {
>                         SetPixel (i, j, 255); // sets all pixels to black
>                         }
>                 }

With this, you generate 640*480 call to SetPixel. You'd better write :

          for (i = 0; i < 640; i++) {
                  for (j = 0; j < 480; j++) {
                         theScreen [i*640+j ] = 255;
                          }
Patrick

--
Patrick Stadelmann <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Vince Tourangeau)
Date: Fri, 27 Jan 1995 16:12:50 GMT
Organization: Carleton University

Patrick Stadelmann ([e-mail]) wrote:
> >
> >         for (i = 0; i < 640; i++) {
> >                 for (j = 0; j < 480; j++) {
> >                         SetPixel (i, j, 255); // sets all pixels to black
> >                         }
> >                 }

> With this, you generate 640*480 call to SetPixel. You'd better write :

>           for (i = 0; i < 640; i++) {
>                   for (j = 0; j < 480; j++) {
>                          theScreen [i*640+j ] = 255;
>                           }
> Patrick

> --
> Patrick Stadelmann <[e-mail]>

Thanks. I noticed this shortly after I posted the original message; I
guess it was sort of "going against the grain" the way it was
originally written. Still, I'd like to speed it uo another 2 to 4
times... anyone know how to do this?
        Vince


- --------------------------------------------------------------------
Flaming Carrot: "Come here and look in the window!"
Herbie: "GADZOOKS! Shakespeare is an AEROBICS INSTRUCTOR!!!"

Vince Tourangeau
Carleton University
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Craig Becker)
Date: 27 Jan 1995 18:39:57 GMT
Organization: Stanford University: Computer Science Department, CA USA

In article <[e-mail]>, [e-mail] (Vince Tourangeau) writes:
|>
|> >           for (i = 0; i < 640; i++) {
|> >                   for (j = 0; j < 480; j++) {
|> >                          theScreen [i*640+j ] = 255;
|> >                           }
|> > Patrick
|>
|> > --
|> > Patrick Stadelmann <[e-mail]>
|>
|> Thanks. I noticed this shortly after I posted the original message; I
|> guess it was sort of "going against the grain" the way it was
|> originally written. Still, I'd like to speed it uo another 2 to 4
|> times... anyone know how to do this?
|>      Vince

Well depending on how much optimization the compiler is doing, this
could speed things up:

  l = 640 * 480;
  for (i = 0; i < l; theScreen[i++] = 255);

This gets rid of the second loop counter and also the multiplication
inside the loop. These could be "optimized away" anyhow, but it's
worth trying.

Another trick to try is treating the array as shorts or longs (instead
of chars) to take advantage of the fact that the bus is more than 8 bits
wide. So something like this:

  unsigned int *intScreen, *end;

  intScreen = (unsigned int *) theScreen;
  end = intScreen + 640 * 480 / sizeof(unsigned int);
  for (; intScreen < end; *(intScreen++) = ~0;

these have not been tried by me on a mac, but have been useful on
other machines.

hope this helps,

craig

+++++++++++++++++++++++++++

>From [e-mail] (AndrewWelc)
Date: 28 Jan 1995 00:36:32 -0500
Organization: America Online, Inc. (1-800-827-6364)

> With this, you generate 640*480 call to SetPixel. You'd better write :
>
>           for (i = 0; i < 640; i++) {                   for (j = 0; j <
> 480; j++) {                          theScreen [i*640+j ] = 255;

>                  }

Even that will be extremely slow.  Try moving a longword at a time,
unrolling the loops somewhat, precalculating the addresses, removing the
multiplication, etc.

Regards,

Andrew Welch
Ambrosia Software, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Charles R. Gray)
Date: 27 Jan 1995 23:53:41 GMT
Organization: Apple Corps of Dallas

[e-mail] (Vince Tourangeau) said:
>> I took the code for direct-to-screen writing from the Mac Programming
>> FAQ, and sped it up as much as I could. However, I was wondering if
>> there's anything I can do to speed it up some more. The following code
>> is what I came up with; it's basically the code from the FAQ with most
>> of the SetPixel stuff moved outside of the loop. This just turns the
>> enitire screen black:
>>
>> void main (void)
>> {
>> // other code omitted for this message...
>>
>>      for (i = 0; i < 640; i++) {
>>              for (j = 0; j < 480; j++) {
>>                      SetPixel (i, j, 255); // sets all pixels to black
>>                      }
>>              }
>> // other code omitted for this message...
>> }
>>
>> void SetPixel ( int h, int v , unsigned long value )
>> {
>>      theScreen [v*640+h ] = value ;
>> }
>>

Improvement #1:
Avoid the overhead of the function call to SetPixel. You could define a
macro,
such as the following:
     #define SETPIXEL(h,v,value)    theScreen [v*640+h ] = value

Improvement #2:
The call to SetPixel has to perform a multiplication and an add to figure out
the
index into theScreen. If you look at your loops, you'll realize that you're
stepping through consecutive locations in the array. All you need to do is
perform an add at each step to get the next index.
This original code:
>>      for (i = 0; i < 640; i++) {
>>              for (j = 0; j < 480; j++) {
>>       theScreen [i*640+j ] = 255
>>                      // Same as SetPixel (i, j, 255);
>>                      }
>>              }
Could become the following code:
    for (i=0; i< 640*480; i++)
        theScreen[i]=255;


__________________________________

[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Vince Tourangeau)
Date: Fri, 27 Jan 1995 21:47:22 GMT
Organization: Carleton University

Craig Becker ([e-mail]) wrote:
> Well depending on how much optimization the compiler is doing, this
> could speed things up:

>   l = 640 * 480;
>   for (i = 0; i < l; theScreen[i++] = 255);

> This gets rid of the second loop counter and also the multiplication
> inside the loop. These could be "optimized away" anyhow, but it's
> worth trying.

> Another trick to try is treating the array as shorts or longs (instead
> of chars) to take advantage of the fact that the bus is more than 8 bits
> wide. So something like this:

>   unsigned int *intScreen, *end;

>   intScreen = (unsigned int *) theScreen;
>   end = intScreen + 640 * 480 / sizeof(unsigned int);
>   for (; intScreen < end; *(intScreen++) = ~0;

> these have not been tried by me on a mac, but have been useful on
> other machines.

> hope this helps,

> craig


I'll give it a shot. Thanks.
        Vince

- --------------------------------------------------------------------
Flaming Carrot: "Come here and look in the window!"
Herbie: "GADZOOKS! Shakespeare is an AEROBICS INSTRUCTOR!!!"

Vince Tourangeau
Carleton University
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Gavriel State)
Date: Mon, 30 Jan 1995 06:54:15 GMT
Organization: University of Waterloo

In article <[e-mail]>,
Vince Tourangeau <[e-mail]> wrote:
>       for (i = 0; i < 640; i++) {
>               for (j = 0; j < 480; j++) {
>                       SetPixel (i, j, 255); // sets all pixels to black
>                       }
>               }

The problem is twofold.  First off, you're only writing one pixel
at a time.  You've got at least 32-bits worth of video-bus bandwidth
to use, and you're only using a quarter of it.

Secondly, your screen-clearing routine requires a *function call*
to write each of those individual pixels.  That means you incur
the penalty of pushing the function params, doing a subroutine
call, doing stack setup and teardown, etc, *every* time you write a
pixel.

A good way to get around the problem is to unroll your loops somewhat,
and try to be writing 32-bits at a time where you can.  You'll have
to ensure that the data is aligned well before you use it, though.

Here's the code for my polygon span-filling routine.  It assumes a
few things, like the depth of the screen, but it adequately demonstrates
how to align your data moves, does some loop unrolling, etc.  Thanks to
Turly O'Connor for his help with the fall-through-switch concept.

Oh - all the setup for the MMU, cursor, etc. takes place in another
function.

This is from my 3D renderer, which I'm really hoping to release
sometime soon.  Of course, if I keep this slackness up, maybe I can
release it at MacHack.....8-)

/* 8-bit specific right now, no Gouraud shading */
void wrDrawSpan (wrUINT16 col, wrINT16 y, wrINT16 startX, wrINT16 endX,
                                 wrUINT16 startShade, wrUINT16 endShade)
{
        wrUINT16                data;
        wrUINT32                data4;
        char                    *ptrPix;
        wrUINT32                *ptrPix4;
        wrINT16                 bytesToFill;
        wrINT16                 longsToFill;

        bytesToFill = endX - startX;
        if (endX < startX)
                return;
        ptrPix = (*pixMapH)->baseAddr + startX;
        ptrPix += y * rowBytes;

        /* For now, assume depth is 8 bits past this point */
        data = wrGetColour8 (col, startShade, startX, y);
        data4 = wrGetColour8_32 (col, startShade, startX, y);

        if (bytesToFill < 16)
        {
            switch (bytesToFill)                                /* Fall Thru Switch */
            {
                case 15: *ptrPix++ = data;
                case 14: *ptrPix++ = data;
                case 13: *ptrPix++ = data;
                case 12: *ptrPix++ = data;
                case 11: *ptrPix++ = data;
                case 10: *ptrPix++ = data;
                case  9: *ptrPix++ = data;
                case  8: *ptrPix++ = data;
                case  7: *ptrPix++ = data;
                case  6: *ptrPix++ = data;
                case  5: *ptrPix++ = data;
                case  4: *ptrPix++ = data;
                case  3: *ptrPix++ = data;
                case  2: *ptrPix++ = data;
                case  1: *ptrPix++ = data;
            }
        }
        else
        {
                /* Align the start pointer */
                switch ((wrUINT32)(ptrPix) & 3)     /* Fall Thru Switch */
                {
                        case 3: *ptrPix++ = data;
                                        bytesToFill--;
                        case 2: *ptrPix++ = data;
                                        bytesToFill--;
                        case 1: *ptrPix++ = data;
                                        bytesToFill--;
            }


            /* Fill 64-bit words */
            longsToFill = bytesToFill >> 3;
            ptrPix4 = (wrUINT32 *)ptrPix;
            while (longsToFill)
            {
                        *ptrPix4++ = data4;
                        *ptrPix4++ = data4;
                        longsToFill--;
            }

                /* Do the end */
                ptrPix = (char *)ptrPix4;
                switch (bytesToFill & 7)                        /* Fall Thru Switch */
                {
                        case 7: *ptrPix++ = data;
                        case 6: *ptrPix++ = data;
                        case 5: *ptrPix++ = data;
                        case 4: *ptrPix++ = data;
                        case 3: *ptrPix++ = data;
                        case 2: *ptrPix++ = data;
                        case 1: *ptrPix++ = data;
            }

        }

}




--
   Gavriel State | 4B Systems Design Engineering | Univ. of Waterloo
- ---------------------------------------------------------------------
     Ros:'Dark, isn't it?'                  Guild:'Not for night.'
                _Rosencrantz_and_Guildenstern_Are_Dead_

---------------------------

>From [e-mail] (David Airey)
Subject: Getting an event outside of the Main Loop
Date: Thu, 26 Jan 1995 00:05:00 -0500
Organization: Cornell University

I understand that Macintosh programs should really only have one main
event loop. To my mind this poses a problem. What if you want to start a
loop with one event and stop the loop when a second event occurs? Because
the loop must continue to completion before the second event is seen, the
loop will never stop. Yet I have seen many programs that manage this.
Playing a movie with one button and stopping it with another. Halting a
search that was taking too long. Stopping a chess program that is
replaying a game. On and on. Yet I don't know how to do this. Send email
to me if you know the answer.

+++++++++++++++++++++++++++

>From [e-mail] (David Stone)
Date: Thu, 26 Jan 1995 15:41:55 GMT
Organization: University of Toronto Chemistry

In article <[e-mail]>,
[e-mail] (David Airey) wrote:
>
> I understand that Macintosh programs should really only have one main
> event loop. To my mind this poses a problem. What if you want to start a
> loop with one event and stop the loop when a second event occurs? Because
> the loop must continue to completion before the second event is seen, the
> loop will never stop. Yet I have seen many programs that manage this.
> Playing a movie with one button and stopping it with another. Halting a
> search that was taking too long. Stopping a chess program that is
> replaying a game. On and on. Yet I don't know how to do this. Send email
> to me if you know the answer.

I have an application that is used to collect real-time data over an
IEEE-488 bus.  Timing is important and I didn't want to get hung up by
anything else so I DID stick an event loop within the collection loop,
which in turn is launched by a mouse click in the main event loop.  At
some point, I'll probably change all this to a Time Manager task.

Elsewhere in the app. I needed something similar, but in this case I wanted
to make sure that updates, etc. as well as mouse and key events where
registered.  So I set up a global "status" variable which lets me know
what mode the user is currently running the program in, and then defined
a sequence of app1Evt messages for different aspects of the interface.
When a "loop process" is needed, I post the appropriate app1Evt message
to start it, which flags the status variable.  Until the appropriate loop
end condition (usually and "OK" or "Cancel" this keeps reposting the same
event message.  When termination is reached, a "clear the status variable"
event gets posted which then does whatever is needed at the end of the
loop.

This sounds horrendously complicated, but it does work!  You have to see it

in action to appreciate it....

Dave Stone

+++++++++++++++++++++++++++

>From [e-mail] (Damon Cokenias)
Date: Sat, 28 Jan 1995 22:56:59 -0800
Organization: a2i network

In article <[e-mail]>,
[e-mail] (David Airey) wrote:

> I understand that Macintosh programs should really only have one main
> event loop. To my mind this poses a problem. What if you want to start a
> loop with one event and stop the loop when a second event occurs? Because
> the loop must continue to completion before the second event is seen, the
> loop will never stop. Yet I have seen many programs that manage this.
> Playing a movie with one button and stopping it with another. Halting a
> search that was taking too long. Stopping a chess program that is
> replaying a game. On and on. Yet I don't know how to do this. Send email
> to me if you know the answer.

Here's how I have done it:

There is only one event loop (not a Macintosh requirement, but makes
things much simpler to debug and maintain).  What happens in response to
an event is determined by the frontmost window.

Imagine you have an application with two windows: one containing an
animation, another that contains controls to pause/play the animation.  As
well you have a menu that provides the play/pause feature.

When a key press is detected by the event loop the following occurs:

Is it a command-key combination?  If yes, go to menu handling, below.
If it is not, determine which window (animation, contols) is frontmost.
Call either ControlWindowKeyPressed() or MovieWindowKeyPressed().

When a mouse click occurs:

Is the click in the menu bar?  If yes, determine which menu was selected.
Call ApplicationOpenDocument(), PauseMovie(), PlayMovie(),
QuitApplication() etc as appropriate.

If not in the menu bar, is it in the drag area of a window? If yes, do
appropriate dragging.  Same goes for resize and zoom areas.

If the click was in the content area, call MovieWindowClicked() or
ControlWindowClicked() as appropriate.

Similar for update events: ask the appropriate window to do its thing.

*****

Doing things in this way leads to an elegant, object-oriented solution.
PowerPlant, TCL, MacApp and other frameworks do it this way.  Truly tricky
people store tables of function pointers hanging off of window RefCons.
It only gets fancier from there.

Check out ftp.sumex-aim.stanford.edu (or a mirror site) for some good
sample source.

-Damon Cokenias

+++++++++++++++++++++++++++

>From [e-mail] (Gregory D. Landweber)
Date: Sun, 29 Jan 1995 03:27:52 -0500
Organization: Harvard University Department of Mathematics

> In article <[e-mail]>,
> [e-mail] (David Airey) wrote:
>
> > I understand that Macintosh programs should really only have one main
> > event loop. To my mind this poses a problem. What if you want to start a
> > loop with one event and stop the loop when a second event occurs? Because
> > the loop must continue to completion before the second event is seen, the
> > loop will never stop. Yet I have seen many programs that manage this.
> > Playing a movie with one button and stopping it with another. Halting a
> > search that was taking too long. Stopping a chess program that is
> > replaying a game. On and on. Yet I don't know how to do this. Send email
> > to me if you know the answer.

There are two ways to do this that I know of.

First, you can break the long task (the loop in your case) into smaller
chunks, and return to the main event loop after each chunk.  If there is
no event pending, then you go back to performing your task.  This requires
that you have a way of saving the current state of your task (such as the
index in your loop).

Secondly, you can use the Thread Manager.  This lets your program have
multiple concurrent threads running simultaneously.  Your main thread has
the event loop, but it spawns other threads to do things like the loop.
The loop thread and main thread could communicate via a global variable,
for instance.  That way, if the "stop" button is pushed, the program can
set a flag for the loop to stop.

I'm sure there are other more creative ways to do this.  Any ideas?

-- Greg Landweber
   [e-mail]
(author of "Greg's Buttons" and "Greg's Browser")

+++++++++++++++++++++++++++

>From [e-mail] (DanParks)
Date: 29 Jan 1995 18:35:39 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (David Airey) wrote:
> I understand that Macintosh programs should really only have one main
> event loop. To my mind this poses a problem. What if you want to start a
> loop with one event and stop the loop when a second event occurs?
Because
> the loop must continue to completion before the second event is seen,
the
> loop will never stop. Yet I have seen many programs that manage this.
> Playing a movie with one button and stopping it with another. Halting a
> search that was taking too long. Stopping a chess program that is
> replaying a game. On and on. Yet I don't know how to do this. Send email
> to me if you know the answer.

[snip Damon Cokenias interesting message ]

David:

If it isn't obvious from the message posted by [e-mail] (Damon
Cokenias), you can call WaitNextEvent() more than one time in your
program. Below is a partial snippet that gives an idea of how this might
be done.

Regards,

Dan Sydow


void Main_Event_Loop( void )
{
   EventRecord  theEvent;

  while ( All_Done == false )
   {
      WaitNextEvent( everyEvent, &theEvent, 15L, nil );

      switch (the_event.what)
      {
         case mouseDown:
            All_Done = true;
            break;
         case keyDown:
            Do_Something();
            break;
      }
   }
}


void  Do_Something( void )
{
   long         i;
   EventRecord  evt;

   for ( i = 0; i < 10000; i++ )
   {
      // Do stuff here. This loop may take time, so give the user
      // the opportunity to break out of the loop at any time by
      // a press on any key:

      if ( WaitNextEvent( keyDownMask, &evt, 0L, nil ) )
         goto escape;
   }

escape:
   // return to calling routine, or post an alert, or ...
}

---------------------------

>From [e-mail] (Kyle Davis)
Subject: Help a dumb father help his son with Mac programming
Date: 9 Jan 1995 20:24:37 GMT
Organization: San Diego State University

PLEASE NOTE: I am posting this message to several groups in the hope of
maximizing response. Your patience is appreciated.


My son, Kyle aged 12, is (in all honesty) quite bright and extremely
interested in the Macintosh and programming. He has programmed in Logo and
in Basic (and is quite creative and good at it). I am, however, entirely
unable to help him move forward. A shame that I can't provide any
direction to help him expand his skills given his high degree of interest.

The net seems to be full of "patches" and game "cheats." These intrigue Kyle.

Is there any advice or direction that you can give me to find a place to
help Kyle start? Are there any books or net resources that explain Mac
programming (in general) or these types of patches and cheats in
particular?  Are there programs that help one create cheats and patches?
How does one look into an existing program? Where does one start?

I'm eager to help Kyle in any way I can, but, unfortunately am quite lost
with absolutely no knowledge where to start.

Any direction or pointers you can provide would be very, very greatly
appreciated.

Thanks

Joel Davis

+++++++++++++++++++++++++++

>From [e-mail] (Mauricio C Tavares)
Date: 9 Jan 1995 15:50:46 -0600
Organization: UTexas Mail-to-News Gateway

While shopping for schroberries, Kyle Davis pondered:

> My son, Kyle aged 12, is (in all honesty) quite bright and extremely
> interested in the Macintosh and programming. He has programmed in Logo and
> in Basic (and is quite creative and good at it). I am, however, entirely
> unable to help him move forward. A shame that I can't provide any
> direction to help him expand his skills given his high degree of interest.
>
> The net seems to be full of "patches" and game "cheats." These intrigue Kyle.
>
        By "patches" and game "cheats," do you mean those little
modifications you do using ResEdit or whatever and change some aspect in
the game such as increase the power/skills/$ of your player?  I a very
simplistic way, those "cheats" are born when some hacker, after spending
days or weeks looking though the executable of a game, finds out the
locations where those variables are stored.  Then, he might change them
to something more interesting.  He might even be able to guess enough of
the logic of the game so that he can afford to be elegant:  infinite
lives and power, get super-duper weapons and treasures (at least their
locations), etc.  I myself used to do that with my old Sinclair games
long before the Mac even existed. =)

Another approach is simply to try to see whether there is any magic key
combination hidden in the game.  Sometimes those were intentionally left
there as an Easter Egg.  the first example the comes to my mind is the
one in the TRS Color Computer 3:  by pressing a certain key combination,
a picture of the CoCo 3 development team is shown.  Another one has to do
with System 7 in the Mac: you can fiddle with some diskette settings to
pop out the name of the developers of the disk drive routines.

Other times, those key combinations were left by accident; they were
originally used to help debug the code and were not removed in the final
version.  Ultima 6 for the PC has lots of those combinations.

> Is there any advice or direction that you can give me to find a place to
> help Kyle start? Are there any books or net resources that explain Mac
> programming (in general) or these types of patches and cheats in
> particular?  Are there programs that help one create cheats and patches?
> How does one look into an existing program? Where does one start?
>

        Well, at this point you need to ask what your son wants to do.  If
it is simply to find a super neat cheat on games nobody ever heard about,
he is pretty much on his own.  First of all, if the cheat was known
already, there would be no point in rediscovering it.  Second, if it is
not known, it is because you do need to spend some time looking for it,
and that is assuming it exists in the first place.  If he really wants to
do that, tell him he will probably need to learn 680000 Assembly and how
the Mac works.  By the second item I mean how the memory is allocated, how
a program is loaded into memory, how resources are shared, and so on.  I
never programmed in Assembly so I canot recommend any good book on 680000
Assembly.

On the other hand, you may consider helping your son learn programming in
the Mac.  This way, he can follow what I call the Unix way:  if you do not
like how an application does something, write your own.  There is a pretty
good BASIC Mac compiler out there.  Programming does teach a little bit of
self-discipline, organization, logic reasoning, and even math; remember
that the trajectory of a gun shell can be approximated by a second degree
polynomial (an ICBM trajectory is more like an ellipse, but that is
another story).  Also, if he writes a nice program, he can consider
selling it as shareware/whatever.  Finally, there are plenty of books
explaining how to program the Mac out there and there is a lot of damn
good Mac programmers (me excluded =( ) in this list that can help him with
his programming problems.


        One thing you may consider as a father:  hunting for those cheats is
potentially dangerous; you are working a very low level in the machine.
One mistaken and you may crash it.  In the worst case, you lose everything
that was in its hard drive.  Also, you are modifying commercial
programs; that may not be seen very nicely by the software houses.  They
can easily say you son is trying to break the code so that he can pirate
it, and that is a crime.  They do remember War Games.

        The choice (and responsibility) is yours.


+++++++++++++++++++++++++++

>From [e-mail] (Kevin Armstrong)
Date: Mon, 09 Jan 1995 22:07:56 -0600
Organization: The University of Texas at Austin

In article <jjdavis-0901951230560001@130.191.208.117>,
[e-mail] (Kyle Davis) wrote:

> My son, Kyle aged 12, is (in all honesty) quite bright and extremely
> interested in the Macintosh and programming. He has programmed in Logo and
> in Basic (and is quite creative and good at it). I am, however, entirely
> unable to help him move forward. A shame that I can't provide any
> direction to help him expand his skills given his high degree of interest.

> The net seems to be full of "patches" and game "cheats." These intrigue Kyle.

> Is there any advice or direction that you can give me to find a place to
> help Kyle start? Are there any books or net resources that explain Mac
> programming (in general) or these types of patches and cheats in
> particular?  Are there programs that help one create cheats and patches?
> How does one look into an existing program? Where does one start?

> I'm eager to help Kyle in any way I can, but, unfortunately am quite lost
> with absolutely no knowledge where to start.

> Any direction or pointers you can provide would be very, very greatly
> appreciated.
>
> Thanks

> Joel Davis

Well, the first thing you need to know is this.  Does your son want to
program the Macintosh, or does he just want to program in Basic or Logo on
the Macintosh.  Being 12, I figure he is probably wanting to produce some
cool new games like Marathon, F-18, or SpaceWord Ho!  I know that was what
I envisioned when I was 12.  Since you are asking for help, I take it that
your son has been asking you for help.

So ask you son what he wants to do.  If he wants to know how to "patch" a
program, he will need to understand lots of things: How does assembly
work, how does the mac work, what do the registers do, what addressing
modes is this instruction using, how is the stack being manipulated.  So
the first place to start would be learning something that would be
considered a bit more advanced than BASIC, (sorry all you BASIC fans).
Pascal or C come to mind.  Some would argue that he should skip Pascal,
but it does require more structure than C so it would impose a bit more
discipline in those early and tough learning stages.  On the other hand, C
and C++ are the languages Apple is pushing everyone to use.  C++ requires
a bit more structure than C, but not a lot.  It does however have some
nice features and clean-ups to the language that I prefer.

The problem now is that either language has a bit of a learning curve.
They are quite different from BASIC.  Especially C.  They also require a
bit more knowledge of the programming environment being used.  BASIC is
pretty forgiving. You run the BASIC development environment, type in your
program, tell it to run, and it runs if there aren't any mistakes.  Pascal
and C are similar, but they have project files and lots of other strange
quirks.  Then you get into Apple's libraries and things get even
stranger.  But, trial and error is a great learning tool.

So where should you go from here?  Talk to you son, ask him what he really
wants to do.  Tell him that it is a lot harder than he may think, but that
you are confident that he could learn how to do it (a good self-esteem
booster there :)).  Then ask him what he wants to do it with.  I really
think that he should start with C or Pascal.  Assembly isn't something you
want to start programming with.  Especially because the only Assembly
Compiler I know of on the Mac is the one in MPW, and MPW is a monster that
I don't want to get too far into.  So what are your choices?  MPW,
Symantec's Think, and the Metrowerks CodeWarrior environments are the most
popular.  You should limit it to Think Pascal or CodeWarrior though.  The
good thing about CodeWarrior is that you get both the C, C++, and Pascal
languages on one CD-ROM, the problem is that it is on a CD-ROM.  You will
also have to decide which CodeWarrior CD-ROM to purchase.  Bronze or Gold
(Platinum comes along later, see csmp.codewarrior for details).  The
Bronze is a 68000 only environment.  It would be good for a 12 year old
using either a 68K based Mac or a Power Mac.  Again, check out the
codewarrior newsgroup for more info.

After picking a programming language, you should probably go to a good
book store and find a beginning programming book or two, and maybe an
intermediate book.  You can always go book shopping again when he has
figured out how to do the easier stuff.  A good way for him to learn is by
translating his BASIC programs to Pascal or C.  That may be hard if there
are graphics or sounds, but if he has any text based programs, he can
translate those fairly easily.

Finally, if he really wants to program on the Mac, you will have to start
looking into buying the Inside Macintosh Books.  They are available on a
CD-ROM (again that CD-ROM hurdle), or as big thick books.  There is also a
program called Think Reference which has all of the Mac API calls through
Original Inside Macintosh 6.  Unfortunately, it is old and hasn't been
kept up by Symantec very well.  Apple is going to release a new reference
package soon.  March comes to mind, but I don't know for sure.  It is
based on the New Inside Mac volumes.  Programming on the Mac will require
more than just reference material though.  So make another trip to the
bookstore and pick out some books on programming the Mac and then let him
have a go at it.

Good luck!

--
Kevin Armstrong
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 10 Jan 1995 04:34:19 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <jjdavis-0901951230560001@130.191.208.117>,
[e-mail] (Kyle Davis) wrote:

< PLEASE NOTE: I am posting this message to several groups in the hope of
< maximizing response. Your patience is appreciated.
<
<
< My son, Kyle aged 12, is (in all honesty) quite bright and extremely
< interested in the Macintosh and programming. He has programmed in Logo and
< in Basic (and is quite creative and good at it). I am, however, entirely
< unable to help him move forward. A shame that I can't provide any
< direction to help him expand his skills given his high degree of interest.
<
< The net seems to be full of "patches" and game "cheats." These intrigue Kyle.
<
< Is there any advice or direction that you can give me to find a place to
< help Kyle start? Are there any books or net resources that explain Mac
< programming (in general) or these types of patches and cheats in
< particular?  Are there programs that help one create cheats and patches?
< How does one look into an existing program? Where does one start?
<
< I'm eager to help Kyle in any way I can, but, unfortunately am quite lost
< with absolutely no knowledge where to start.
<
< Any direction or pointers you can provide would be very, very greatly
< appreciated.
<
< Thanks
<
< Joel Davis

Kyle would do better to write his own game(s) than to try to cheat on
others.  Logo and Basic ar OK for the beginner but he should move on to
languages like Pascal or C (eventually to an object-oriented language like
C++/smalltalk or others).

Writing a simple game like a tic-tac-toe player or something that
automatially generates mazes and then tries to solve them or competes with
the user who is concurrently trying to solve it, or any of a hundred
others will help him to move forward.  Any sort of game with simple
graphics will be fun and interesting.

I will recommend that you purchase the CodeWarrior environment for him.
It's $99 for educational users (I'm sure a bright 12 year old is in school
:)  It comes with pascal/C/and c++ compilers.  I'm sure he'll go to town
with it.

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Michael Hecht)
Date: 10 Jan 1995 05:10:14 GMT
Organization: Vnet Internet Access, Charlotte, NC -  [e-mail]

Joel,

My best suggestion is to get a copy of Resorcerer. It is a resource editor
similar to ResEdit, but it includes an editor for 68K machine code that
has some patching capabilities, like replacing a set of instructions with
"no-op's" and branching around segments of code. I believe the manual even
includes some tips on how to patch applications. Resorcerer is from

   Mathemaesthetics Inc.
   PO Box 156
   Chestnut Hill, MA 02167
   ph. 617-738-8803
   FAX [phone]
   e-mail: [e-mail]

He may, however, find 68K machine code a bit overwhelming. I remember
being somewhat overwhelmed by Z80 machine code at around age 14, but
disassembling the ROMs of my TRS-80 was a great learning experience!

Perhaps this will pique your son's interests in programming with a
higher-level language (where he should really be spending his time anyway
:-). You might also look into "Thin C" (a starter version of THINK C) from
Symantec. It comes with several tutorials.

Dave Mark's book, "Macintosh Programming Primer using C" (or something
like that--it's a red book), worked for my wife when she needed to learn
some Mac skills.

Good luck!
--Michael

=======================================================================
Michael P. Hecht             [e-mail]              Durham, NC USA

+++++++++++++++++++++++++++

>From [e-mail] (Ben Hamilton)
Date: 09 Jan 1995 22:37:27 GMT
Organization: The ChatterBox  [phone]

Hi Kyle,
    From the hands of a 17 year old programmer, the best way to start is buy
him a basic book on C
(The one I learned from was the awe holy book o "C By Example" from "Que" you
can find it at hastings.
After learing it(with more frustartion and time than you think) move on to
"Macintosh Programming Primer" by Mark Reed published by Addison Wesley. I
started in the ...7th or8th grade I guess that would made me about 13 or 14
so your son has a decent head start. I worked at the "Texas Woman's
University"
computer department my first year of high school doing chaos theory work.(FI)
Frequency analysis and so forth. Anyhow they were smart enough to put that
stuff on a mac. The mac is suprisingly ,scarcely coded on at the scientific
level. Anyhow I like talking about young programmers 'cause it's a field
where know how surmounts age.

I'm assuming you will buy a compiler for the lad.
Get CodeWarrior if you have a silver disk spinner.
Or get Symantec if you don't.

Don't make the mistake I made. Don't let him fear getting his hands dirty.
Mess up a shit load you'll do better in the long run. Learn how to program
Windows and Dos. (So you can insult their puny(?) OS)

void And send me a copy of his award winning program(Free and register(A1)ed
that is);


+++++++++++++++++++++++++++

>From [e-mail] (Ernie Soffronoff)
Date: 10 Jan 1995 19:21:01 GMT
Organization: StarNet Communications, Inc

A few things got me on the road to Mac programming... (tho I still have a
looong way to go):

1)  AppMaker.  This program will generate the Mac interface for a
program, which saves a lot of time.  By saving a lot of time you're
better able to write a lot of programs.  I also learned more about Mac
programming from reading the AppMaker generated code than by any other means.

2) Think Reference.  This makes it easy to look up stuff you don't
understand when reading other people's (and AppMaker's) code.  There's a
new tool coming out that does about the same thing, but I doubt it can top
TR.

3)  Writing After Dark screensavers.  Like with AppMaker, After Dark
takes care of a lot of the details for you and you just have to plug in
the functionality.  This is (IMO) the greatest way to get started with
Mac graphics programming (an area where AppMaker falls short).  You won't
necessarily be writing "games" but the results are quick and the product
is easy to share.

--Ernie

+++++++++++++++++++++++++++

>From [e-mail] (emb121)
Date: 11 Jan 1995 22:12:25 GMT
Organization: Penn State University, Center for Academic Computing

In article <jjdavis-0901951230560001@130.191.208.117>
[e-mail] (Kyle Davis) writes:

> My son, Kyle aged 12, is (in all honesty) quite bright and extremely
> interested in the Macintosh and programming. He has programmed in Logo and
> in Basic (and is quite creative and good at it). I am, however, entirely
> unable to help him move forward. A shame that I can't provide any
> direction to help him expand his skills given his high degree of interest.

I started programming in BASIC in about fifth grade on an Apple IIe.
When I moved over to the Mac I bought THINK Pascal but never really got
into it.  Now I'm using FutureBasic (Zedcor, Inc. ZEDCOR forum on
America Online; phone [phone]; I think they have some special
package deal going for under $100 but you'll have to call to be sure),
and I am actually able to do serious things with it.  The documentation
is much more friendly than what I got with THINK Pascal, and the
FutureBasic documentation covers basic Macintosh tools like sound,
QuickDraw, and QuickTime playback so you don't have to buy fifty other
reference books just to get started.  What I liked most was that I was
able to start with built-in, simple to use FutureBasic commands and
later switch over to the more powerful Mac toolbox calls as needed.


-Eric Bennett ([e-mail])
FTP/HTTP://emb121.rh.psu.edu

Drawing on my fine command of the language, I said nothing.
-Robert Benchley

+++++++++++++++++++++++++++

>From [e-mail] (Gregory S. Hendricks)
Date: 12 Jan 1995 22:04:44 GMT
Organization: University of Southern Mississippi

Kyle Davis ([e-mail]) wrote:
: PLEASE NOTE: I am posting this message to several groups in the hope of
: maximizing response. Your patience is appreciated.


: My son, Kyle aged 12, is (in all honesty) quite bright and extremely
: interested in the Macintosh and programming. He has programmed in Logo and
: in Basic (and is quite creative and good at it). I am, however, entirely
: unable to help him move forward. A shame that I can't provide any
: direction to help him expand his skills given his high degree of interest.

: The net seems to be full of "patches" and game "cheats." These intrigue Kyle.

: Is there any advice or direction that you can give me to find a place to
: help Kyle start? Are there any books or net resources that explain Mac
: programming (in general) or these types of patches and cheats in
: particular?  Are there programs that help one create cheats and patches?
: How does one look into an existing program? Where does one start?

: I'm eager to help Kyle in any way I can, but, unfortunately am quite lost
: with absolutely no knowledge where to start.

: Any direction or pointers you can provide would be very, very greatly
: appreciated.

: Thanks

: Joel Davis

   Your son should get Zedcor's Future Basic for the Mac. He should also get
some Inside Mac books and a beginning Mac programming book on how to use
the Mac toolbox. Of course, to understand those books, he will
need to have some knowledge of Pascal functions/procedures (and the C or
C++ language), so it would probably be better for him to give up Basic and
learn Pascal or C instead. Learning the Toolbox is what sets the Mac apart
from programming for other types of computers, and I'm not sure what kind
of documentation comes with Future Basic. A lot of this will also depend
on your son's level of computer understanding, since a big part of Mac
programming is managing memory - not an easy task, even for grown ups like
myself. Unfortunately, most game cheats that I know of are usually written
as extensions, so getting away from the memory aspect of it is impossible
(extensions actually become a part of your system software when the Mac
boots up - more extensions = more RAM usage).
   As far as cheats go, writing one would require knowing how the program
works, so you would have to get the code from the developers of the game,
which would require their permission. I haven't the slightest idea about
how to go about doing that, except to contact (e-mail) other cheat
programmers or game programmers. The AOL Developers forum has a SIG for
game developers, so that might be a good place to start. Hope all this
stuff has helped. Maybe some game programmers out there could comment. I'm
fairly new to Mac programming myself.........

Shane

+++++++++++++++++++++++++++

>From [e-mail] (Ivan Cavero Belaznde)
Date: Thu, 12 Jan 1995 21:13:18 -0500
Organization: Avid Technology, Inc.

> In article <jjdavis-0901951230560001@130.191.208.117>,
> [e-mail] (Kyle Davis) wrote:
>
> > My son, Kyle aged 12, is (in all honesty) quite bright and extremely
> > interested in the Macintosh and programming. He has programmed in Logo and
> > in Basic (and is quite creative and good at it). I am, however, entirely
> > unable to help him move forward. A shame that I can't provide any
> > direction to help him expand his skills given his high degree of interest.
>
> > The net seems to be full of "patches" and game "cheats." These
intrigue Kyle.
>
> > Is there any advice or direction that you can give me to find a place to
> > help Kyle start? Are there any books or net resources that explain Mac
> > programming (in general) or these types of patches and cheats in
> > particular?  Are there programs that help one create cheats and patches?
> > How does one look into an existing program? Where does one start?
>
> > I'm eager to help Kyle in any way I can, but, unfortunately am quite lost
> > with absolutely no knowledge where to start.
>
> > Any direction or pointers you can provide would be very, very greatly
> > appreciated.
> >
> > Thanks
>
> > Joel Davis

It depends on what he wants to do, as others have said; if he does truly
want to learn programming on the Mac, and he's used BASIC and LOGO, start
him up with either HyperCard or SuperCard - they will serve as a useful
introduction to the various Mac and OO-like concepts (events, message
passing, ownership hierarchy, etc); it's easy enough to get started and
build pretty real stuff as he gets better (you can unleash ResEdit and the
boatload of XCMD libraries out there as he starts butting his head against
HC's limits). Plus it will wean him from BASIC's evil ways. Then drop him
into THINK (I'd rather say CW, but there's nothing like Dave Mark's
"Macintosh Programming Primer" for it...). Finally, introduce him to the
various programming resources around the net (FAQs, WWW pages, csmp*, the
CSMP digests, ftp source sites, etc).

Hope this helps,

-Ivan
- ---
Ivan Cavero Belaznde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Miehs)
Date: 14 Jan 1995 08:02:50 GMT
Organization: Microplex Pty Ltd

Newsgroups: comp.sys.mac.programmer
Subject: Re: Help a dumb father help his son with Mac programming

In message <[e-mail]>, [e-mail]
(Mauricio C Tavares) writes:

>While shopping for schroberries, Kyle Davis pondered:
>
>> My son, Kyle aged 12, is (in all honesty) quite bright and extremely
>> interested in the Macintosh and programming. He has programmed in Logo and
>> in Basic (and is quite creative and good at it). I am, however, entirely
>> unable to help him move forward. A shame that I can't provide any
>> direction to help him expand his skills given his high degree of interest.
>>
>> The net seems to be full of "patches" and game "cheats." These intrigue
Kyle.

Unfortunately, as machines and operating system become more powerful, they
generally become more difficult to program. I started programming years ago on
an Apple ][ in basic, and the on to 6502. All this being said and done, The Mac

is a great machine, and programing them can be quite rewarding, if not
frustrating at times. I would definitely recommend purchasing an "Idiots guide
to C" or something along those line. These books are usually writen for the
simple minded, (like myself). For the first year, it is not important to be
able to use the Mac Interface. It is much more important to get a firm
grounding in C and C++ so that when you finally do make the changeover from
ANSI C you will have a huge head start.

Later on, when the need arises, purchase a copy of the Inside Mac Series (or
whatever they are called now).

In summary, I would recommend getting
A C Compiler (capable of C++) so CodeWarrior, or Think C... etc
A Book on programming in ANSI C. - The Macintosh stuff can wait till later.

Good luck, and happy programming...

[e-mail]







+++++++++++++++++++++++++++

>From [e-mail] (Ritchie Brock)
Date: 10 Jan 1995 08:58:53 -0600
Organization: Bell-Northern Research, Richardson, TX

In article <[e-mail]>,
Mauricio C Tavares <[e-mail]> wrote:
>While shopping for schroberries, Kyle Davis pondered:
>
>> My son, Kyle aged 12, is (in all honesty) quite bright and extremely
>> interested in the Macintosh and programming. He has programmed in Logo and
>> in Basic (and is quite creative and good at it). I am, however, entirely
>> unable to help him move forward. A shame that I can't provide any
>> direction to help him expand his skills given his high degree of interest.
>>
>> The net seems to be full of "patches" and game "cheats." These intrigue Kyle.
>>
>Another approach is simply to try to see whether there is any magic key
>combination hidden in the game.  Sometimes those were intentionally left
>there as an Easter Egg.  the first example the comes to my mind is the
>one in the TRS Color Computer 3:  by pressing a certain key combination,
>a picture of the CoCo 3 development team is shown.  Another one has to do
>

Wow!  Another person who used a CoCo 3.  Now where are all those back issues
of Rainbow?!

Joe
--
* Joseph A. Bell (NOT Ritchie Brock)                       *
* Northern Telecom / Bell-Northern Research                *
* Email: [e-mail]                                     *

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Ryan Jankowski)
Date: 17 Jan 1995 03:38:29 GMT
Organization: The Greater Detroit Free-Net


Personally, I would learn Pascal first. Though Pascal is being
phased out, it was easier to learn in my opinion, and most of
the toolbox references that your son will need are written in
Pascal. Though he may eventually graduate to C (as I did, and I'm
only 15) right now, Pascal is the best thing for him.
 Any questions? I've been at this for about a year and a half,
so if you or your son needs any help, just drop me a message.
 -JRJ
[e-mail]
--

+++++++++++++++++++++++++++

>From John Kawakami <[e-mail]>
Date: Mon, 16 Jan 1995 19:38:37 GMT
Organization: Xplain Corp.

In article <3f491s$[e-mail]>, [e-mail]
(Gregory S. Hendricks) wrote:

> Kyle Davis ([e-mail]) wrote:
> : My son, Kyle aged 12, is (in all honesty) quite bright and extremely
> : interested in the Macintosh and programming. He has programmed in Logo and
> : in Basic (and is quite creative and good at it). I am, however, entirely
> : unable to help him move forward. A shame that I can't provide any
> : direction to help him expand his skills given his high degree of interest.
> : Joel Davis
>
>    Your son should get Zedcor's Future Basic for the Mac. He should also get
> some Inside Mac books and a beginning Mac programming book on how to use
> the Mac toolbox...

Find out where the nearest mac-friendly computer oriented bookstores are,
and let him loose for a few hours.  He won't find much info on "game
cheats" but he should find a few interesting books.  (Oh yeah, get him
MacTech too!)

One book to buy would be "Learning C on the Macintosh" by Dave Mark (can
be ordered for $31.45 from the Mail Order Store
[[e-mail]]).  This book teaches C and includes a C compiler
for you to experiment with.

FYI - if you decide to get your son a C++ compiler (this will probably
happen before age 18), remember to take advantage of EDUCATIONAL DISCOUNTS
from the two main compiler vendors: Symantec and Metrowerks.

Another important resource is a good library.  I used to ride the bus to
the local colleges to get at the books.  (It also helped that there were
terminals in the libraries, and I could use a friend's cyber account.)
Most public libraries around here tend to have books like "10,001 Excel
Trix" or "Borneo Adventures with Flight Simulator 2". :)

- -MacTech Magazine--------------------------------------------------
PO Box 250055, Los Angeles, CA 90025, 310-575-4343, Fax:[phone]
For more info, anonymous ftp: ftp.netcom.com, cd to /pub/xp/xplain
email to the following @xplain.com : custservice, editorial,
adsales, marketing, accounting, pressreleases,
progchallenge, publisher, info

+++++++++++++++++++++++++++

>From [e-mail] (Robert A. Uhl)
Date: 17 Jan 1995 15:24:55 GMT
Organization: University of Denver

In article <3ffe3l$[e-mail]>,
Jeremy Ryan Jankowski <[e-mail]> wrote:
>
>Personally, I would learn Pascal first. Though Pascal is being
>phased out, it was easier to learn in my opinion, and most of
>the toolbox references that your son will need are written in
>Pascal. Though he may eventually graduate to C (as I did, and I'm
>only 15) right now, Pascal is the best thing for him.
> Any questions? I've been at this for about a year and a half,
>so if you or your son needs any help, just drop me a message.

  I disagree. C is probably best. I learned it at 14, and I'm sure that
your son will be able to. There is a book by Steve Oualline and from
O'Reilly and Associates that teaches C. I cannot recall the name, but
any good bookstore (not Waldenbooks or B. Dalton, but a _bookstore_)
should have it in stock. It's ~10 from what I recall.

  Pascal is on the way out. It is seldom used. Why spend time learning a
language which will never be used? Learn C, suffer a week or two, and
get on with the business of programming great apps.
--
- ------------------------------------------------------------------------
| Bob Uhl | Spectre                  | `In touto nika' +                 |
| U of D  | Baron Robert von Raetzin | http://mercury.cair.du.edu/~ruhl/ |
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Joe Gervais)
Date: 18 Jan 1995 13:01:28 -0800
Organization: Expersoft

In article <3f80fa$[e-mail]>,
Andrew Miehs <[e-mail]> wrote:
>Newsgroups: comp.sys.mac.programmer
>Subject: Re: Help a dumb father help his son with Mac programming
>
>In message <[e-mail]>, [e-mail]
>(Mauricio C Tavares) writes:
>
>>While shopping for schroberries, Kyle Davis pondered:
>>
>>> My son, Kyle aged 12, is (in all honesty) quite bright and extremely
>>> interested in the Macintosh and programming. He has programmed in Logo and
>>> in Basic (and is quite creative and good at it). I am, however, entirely
[SNIP]
>
>Unfortunately, as machines and operating system become more powerful, they
>generally become more difficult to program. I started programming years ago on
[SNIP]
>simple minded, (like myself). For the first year, it is not important to be
>able to use the Mac Interface. It is much more important to get a firm
>grounding in C and C++ so that when you finally do make the changeover from
>ANSI C you will have a huge head start.


Excellent point. In particular, CodeWarrior's SIOUX library
allows basic text I/O in a window that it creates for you.
Nice way to avoid mucking with the Mac Toolbox until one
has a good grasp of Pascal/C/C++ programming in general.

Also a rather handy way to get core pieces of a project
running/debugged - simple menu driven text I/O to test out
the various functional objects you've created. When it's all
shaken out, convert it into a full-blown Mac app. Yeah, I
know it sounds ugly, but I'm a unix guy at heart. :)

[SNIP]
>In summary, I would recommend getting
>A C Compiler (capable of C++) so CodeWarrior, or Think C... etc
>A Book on programming in ANSI C. - The Macintosh stuff can wait till later.

What he said. :) A favorite C++ book of mine (for starting)
is by Lippman. Easy to read but not too fluffy.

Good luck!

Cheers,

-Joe


+++++++++++++++++++++++++++

>From [e-mail] (Nigel Higgins)
Date: Thu, 19 Jan 1995 05:37:45 GMT
Organization: The Education Technology Centre of British Columbia. (Canada)


In a previous article, [e-mail] (Jeremy Ryan Jankowski) says:

>
>Personally, I would learn Pascal first. Though Pascal is being
>phased out, it was easier to learn in my opinion, and most of
>the toolbox references that your son will need are written in
>Pascal. Though he may eventually graduate to C (as I did, and I'm
>only 15) right now, Pascal is the best thing for him.
> Any questions? I've been at this for about a year and a half,
>so if you or your son needs any help, just drop me a message.
> -JRJ
>[e-mail]
>--
>

Sounds exactly like me. I'm 16, started using THINK Pascal at 14, and
just last year I bought CodeWarrior. If your son is smart, give him the
tools he needs (THINK Pascal, THINK C, or CodeWarrior) some good
programming books by Dave Mark and he should be able to find his way from
there.

Good luck.

+++++++++++++++++++++++++++

>From Tom Rowlands <[e-mail]>
Date: Sat, 21 Jan 95 08:30:20 +1000 (AEST)
Organization: Best Before A Week Last Tuesday


In article <3fgng7$[e-mail]>, Robert A. Uhl writes:

>
> In article <3ffe3l$[e-mail]>,
> Jeremy Ryan Jankowski <[e-mail]> wrote:
>
>Personally, I would learn Pascal first. Though Pascal is being
>phased out, it was easier to learn in my opinion, and most of
>the toolbox references that your son will need are written in
>Pascal. Though he may eventually graduate to C (as I did, and I'm
>only 15) right now, Pascal is the best thing for him.
> Any questions? I've been at this for about a year and a half,
>so if you or your son needs any help, just drop me a message.

Nope. I diagree.

Pascal is a nasty language. Personally, I learn any lanugage I can. (If there is
a book teaching you it, I will learn it. Which is rather pointless, but it9s
interesting.) Learn C. Pascal is phazed out now, noone uses it much.

BTW: Drop me a line if you want!

Tom Rowlands
[e-mail]
(14 year old Led Zeppelin freak.)

+++++++++++++++++++++++++++

>From [e-mail] (Mark D. Gerl)
Date: 26 Jan 1995 14:56:12 GMT
Organization: George Washington University

John Kawakami ([e-mail]) wrote:
: One book to buy would be "Learning C on the Macintosh" by Dave Mark (can
: be ordered for $31.45 from the Mail Order Store
: [[e-mail]]).  This book teaches C and includes a C compiler
: for you to experiment with.

Actually, most people can recommend ANY of the books written by Dave Mark.
The C++ counterpart to this suggested C book is also excellent, and a few
years newer.  Your son would probably do better to start here...


---------------------------

>From [e-mail] (Miguel Cruz)
Subject: How can I tell if a driver (eg MacTCP) is open
Date: Mon, 30 Jan 1995 20:37:11 GMT
Organization: Unaffiliated

Can someone point me towards a snippet which would demonstrate how to
determine whether a specified driver is open? I would like to open MacTCP
but only if I am already sure that it has been opened. I'm sure it's
possible, as there is some dcmd which came with MacsBug on the
codewarrior CD which is able to give status information on all drivers.
I've combed through IM and not found any terribly germane information.

Thanks.

miguel

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Mon, 30 Jan 1995 16:13:38 -0600
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>, [e-mail] (Miguel Cruz) wrote:

>Can someone point me towards a snippet which would demonstrate how to
>determine whether a specified driver is open? I would like to open MacTCP
>but only if I am already sure that it has been opened. I'm sure it's
>possible, as there is some dcmd which came with MacsBug on the
>codewarrior CD which is able to give status information on all drivers.
>I've combed through IM and not found any terribly germane information.

#ifdef __LOWMEM__
#   define UTABLEBASE   LMGetUTableBase()
#   define UNITNTRYCNT  LMGetUnitNtryCnt()
#else
#ifdef __SYSEQU__
#   define UTABLEBASE   (*(DCtlHandle **)UTableBase)
#   define UNITNTRYCNT  (*(short *)UnitNtryCnt)
#else
#   define UTABLEBASE   UTableBase
#   define UNITNTRYCNT  UnitNtryCnt
#endif
#endif

#ifndef dOpened
#   define dOpened      0x0020
#endif

short GetDrvrRefNum(Str255 drvrName)
{
    short unitNum;
    DCtlPtr curDCtlPtr, *curDCtlHndl, **UTableEntry;
    DriverPtr curDrvrPtr;

    /* Start at UTableBase */
    UTableEntry = UTABLEBASE;

    /* Walk through the Unit Table */
    for(unitNum = 0; unitNum < UNITNTRYCNT; ++unitNum) {

        /* Get the entry at this point in the unit table and increment */
        curDCtlHndl = *UTableEntry++;

        if(curDCtlHndl != nil) {

            /* Dereference the control entry */
            curDCtlPtr = *curDCtlHndl;

            /* Get the pointer to the driver */
            curDrvrPtr = (DriverPtr)curDCtlPtr->dCtlDriver;

            /* If this is a RAM driver, it's a handle. ROM is a pointer */
            if((curDCtlPtr->dCtlFlags & dRAMBased) && (curDrvrPtr != nil))
                curDrvrPtr = *(DriverPtr *)curDrvrPtr;

            /* Does the driver name match? */
            if(curDrvrPtr != nil)
                if(EqualString(drvrName, curDrvrPtr->drvrName,
                               false, true))
                    return(~unitNum);
        }
    }
    return(0);
}

Boolean IsDriverOpen(Str255 drvrName)
{
    short refNum;
    DCtlHandle driverHandle;

    refNum = GetDrvrRefNum(drvrName);

    if(refNum == 0)
        return false;

    driverHandle = GetDCtlEntry(refNum);

    if((*driverHandle)->dCtlFlags & dOpened)
        return true;
    else
        return false;
}

pr
--
Pete Resnick - [e-mail]
Doctoral Student - Philosophy Department, UIUC
Other connections to the world are tenuous at best

---------------------------

>From [e-mail] (Ryan Richard Koopmans)
Subject: Quality of Random()
Date: 13 Jan 1995 02:05:10 GMT
Organization: Rice University

How good is the Random() function in ROM?  I set randSeed to
TickCount, but is that enough?  I'm making heavy use of the
function, and I'm wondering if it would be good to use my
own algorthim.

Any thoughts?
--

Ryan Koopmans  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Thu, 12 Jan 1995 23:47:34 -0500
Organization: One Step Beyond

[e-mail] (Ryan Richard Koopmans) wrote:

) How good is the Random() function in ROM?  I set randSeed to
) TickCount, but is that enough?  I'm making heavy use of the
) function, and I'm wondering if it would be good to use my own
) algorthim.

It's fast but not very good.  I believe it uses the simple linear
congruent method to generate random numbers.  These type of random
number generators exhibit a rather short "period" and are also have
poor k-space distribution.

However, they are very fast.  If you are not doing simulations work,
then either Random() nor rand() from the standard C libs should be
good enough.

If you feel that you need a more sophisticated algorithm, look in
the book "Numerical Recepies in C" (or Pascal or Fortran) and you
will find a chapter describing various random number generators in
detail, along with their pros and cons.  Knuth also discusses this
stuff, but I personally find his writing a bit obtuse.

Don't try to roll your own unless you have a very good background
in statistics and numerical methods.  There is a lot of hard found
magic involved in creating a good random number generator.

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     +1.212.947.6507
One Step Beyond         and Network Consulting           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Rod Hanks)
Date: 17 Jan 1995 22:18:37 GMT
Organization: BenchBuilt Software Co.


How good is Random()?  Its lousy.

I do a lot of mathematical simulations where I need a good uniform variate.
Don't even think of using Random() for this.  There is a good algorithm
in "Numerical Recipes in PASCAL" (which is probably also in "Numerical Recipes
in C", I program in C but I don't think the C copy was out when I
bought it).

Even with their algorithm, I had to do a little playing with the output to
make sure I had the same chance of getting a number between 0 and 0.25 as I
did to get one between 0.75 and 1.0.

Sorry I don't know the authors off hand, cause they really deserve an Attaboy.

Anybody interested in doing stuff with numbers on a computer should have this
book.

Thanks,
Rod

+++++++++++++++++++++++++++

>From [e-mail] (Rick Holzgrafe)
Date: Fri, 13 Jan 1995 21:14:47 GMT
Organization: Semicolon Software

In article <3f4n4m$[e-mail]>, [e-mail] (Ryan
Richard Koopmans) wrote:

> How good is the Random() function in ROM?  I set randSeed to
> TickCount, but is that enough?

Robert Mah has already addressed the quality of the algorithm. I just want
to suggest that you use the return from GetDateTime as your seed instead
of the return from TickCount. TickCount starts at zero every time you
restart your Mac, so you have a much greater likelihood (small perhaps,
but greater nonetheless) of starting from the same seed occasionally.

-- Rick Holzgrafe, a member of the Taligentsia
   [e-mail]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Howard Berkey)
Date: 19 Jan 1995 18:48:32 GMT
Organization: Premenos Corp.

In article <[e-mail]>,
Robert Mah <[e-mail]> wrote:
>[e-mail] (Ryan Richard Koopmans) wrote:
>
>) How good is the Random() function in ROM?  I set randSeed to
>) TickCount, but is that enough?  I'm making heavy use of the
>) function, and I'm wondering if it would be good to use my own
>) algorthim.
>
>It's fast but not very good.  I believe it uses the simple linear
>congruent method to generate random numbers.  These type of random
>number generators exhibit a rather short "period" and are also have
>poor k-space distribution.


I would be very surprised if it was anything but a linear congruency
generator.  While the period is (fairly) short, proper seeding can
help.  I'm fuzzy on the K-space argument (I'd have to reach for Knuth
volume 2 and it's uncivilized to do that before noon :-), but you can
get at least a reasonable distribution using linear congruent methods
with proper seeding.

>
>However, they are very fast.  If you are not doing simulations work,
>then either Random() nor rand() from the standard C libs should be
>good enough.
>

Hmm.  I used Random() several years ago for monte-carlo simulations
in a Physical Chemistry class and the results were satisfactory.  For
more sophisticated simulations you're probably right, though.


>Don't try to roll your own unless you have a very good background
>in statistics and numerical methods.  There is a lot of hard found
>magic involved in creating a good random number generator.
>

Like I said, in the past I've been able to make Random() random
enough.  At least for my academic purposes, that is...

True random numbers (i.e. not pseudorandom) would be difficult (almost
impossible?) although I have heard of some pretty adventurous
attempts, some involving homebrew hardware additions to the computer.


-H-

--
Howard Berkey                                     [e-mail]
                   Windows '95 == Macintosh '84

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Sat, 21 Jan 1995 00:40:41 -0500
Organization: One Step Beyond

[e-mail] (Howard Berkey) wrote:

) Robert Mah <[e-mail]> wrote:
)
) >[e-mail] (Ryan Richard Koopmans) wrote:
) >
) > ) How good is the Random() function in ROM?  I set randSeed to
) >
) > It's fast but not very good.  I believe it uses the simple linear
) > congruent method to generate random numbers.  These type of random
) > number generators exhibit a rather short "period" and are also have
) > poor k-space distribution.
)
) I would be very surprised if it was anything but a linear congruency
) generator.  While the period is (fairly) short, proper seeding can
) help.  I'm fuzzy on the K-space argument (I'd have to reach for Knuth
) volume 2 and it's uncivilized to do that before noon :-), but you can
) get at least a reasonable distribution using linear congruent methods
) with proper seeding.

Say k = 3 (i.e. real space).  Generate a whole bunch of random points
and plot them in 3-D space.  If the random number generator is "good"
the points will tend to fill up the space more or less evenly (i.e.
randomly).  However, the points generated by linear congruent methods
tend to congregate along k-1 dimensional "planes" (in this case, real
2-D planes).

The number of such planes is dependent upon the choice of constants
used.  Some generators will see as few as 32 planes or lower.


But there's yet another problem I forgot about...

The randomness of the low order bits is often far less than the
randomness of the number as a whole.  Therefore doing things like...

  n = Random() % 10

will not yield very random results.  Instead you should try something
like...

  n = 1 + ( 10L * (long)Random() / (kMaxRand + 1) )

I only know this semi-useless trivia because I was forced to take
two (three? four?) classes on this "stuff" in school.


) True random numbers (i.e. not pseudorandom) would be difficult (almost
) impossible?) although I have heard of some pretty adventurous
) attempts, some involving homebrew hardware additions to the computer.

I recall a book I read way back when, about an underground group that
made "true" random number generators using specialized hardware.  They
used this device to outguess laser satalites that tried to zap chip
smugglers as they drove their souped up cars in the Texas desert.  It
turned out to be a government (or corporate?) plot of some sort...

Creating a true random number generator using turing machines (i.e.
digital computers) is impossible.

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     [phone]
One Step Beyond         and Network Consulting           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert A. Uhl)
Date: 23 Jan 1995 09:04:21 GMT
Organization: University of Denver

In article <[e-mail]>,
Robert Mah <[e-mail]> wrote:
>Creating a true random number generator using turing machines (i.e.
>digital computers) is impossible.

  Actually, it is possible if one hooks up certain op-amps in such a
fashion as to generate a chaotic sequence. With the right feedback loops
and A/D conversions, the numbers therefrom are as random as they get.
Well, they _are_ chaotic, but it is close enough to random for
_anything_ that you will be using it for.

--
- ------------------------------------------------------------------------
| Bob Uhl | Spectre                  | `In touto nika' +                 |
| U of D  | Baron Robert von Raetzin | http://mercury.cair.du.edu/~ruhl/ |
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Mon, 23 Jan 95 01:39:37 GMT
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer),
[e-mail] (Dan Lakeland) writes:

> Hmm, I thought Random() was supposed to be fairly good (the QD macintosh
> version). But of course most people don't need a very good random number
> generator.

It's reasonable: it's the same LCG that is described as a "minimal standard" in
the Parks and Miller paper in CACM vol 31 no 10.  It's good enough for general
use, but of course, "mathematical simulations where I need a good uniform variate"
doesn't fall into this category.

Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Thu, 26 Jan 1995 23:27:49 -0500
Organization: One Step Beyond

[e-mail] (Eric Traut) wrote:

) > > How good is Random()?
)
) The original author of Random() decided it would return numbers in the
) range -32767 to 32767. The algorithm used internally to generate
) pseudo-random numbers generates a 16-bit quantity. Since this quantity
) could be outside the specified range (i.e. it could be -32768), the
) routine was coded to simply return zero in this case.

Lars Farm <[e-mail]> wrote that he read a paper written by the
folks who wrote Random() that said that it worked internally with long
int's and simply returned the low order word.

>From a quick scan of the 68K assembly for _Random there's a lot of word
swapping and such going on, which I assume is to handle longword multiplies
on the 68000.  This supports Lars.  However, it does indead do an explicit
check for -32768 at the end (this strikes me as sort of funny).

Could you please clarify for those of us who are curious?


) When we ported Random() to C last year (so it could be compiled for
) PowerPC), we were tempted to change the algorithm to fix the problem, but
) decided not to for compatibility reasons.

Are you being serious here?  Did anyone REALLY rely upon the a certain
sequence of values from Random()?  And was it Microsoft?

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     [phone]
One Step Beyond         and Network Consulting           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Eric Traut)
Date: 25 Jan 1995 07:23:18 GMT
Organization: Apple Computer, Inc.

>>How good is Random()?

The Random() function implemented in QuickDraw does a pretty good job at
random number generation. However, it has one flaw which prevents it from
generating a good random distribution. The original author of Random()
decided it would return numbers in the range -32767 to 32767. The algorithm
used internally to generate pseudo-random numbers generates a 16-bit
quantity. Since this quantity could be outside the specified range (i.e. it
could be -32768), the routine was coded to simply return zero in this case.
That means that Random() is twice as likely to return zero than any other
number.

When we ported Random() to C last year (so it could be compiled for
PowerPC), we were tempted to change the algorithm to fix the problem, but
decided not to for compatibility reasons.

Eric Traut
MacOS Engineer
Apple Computer, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Dan Lakeland)
Date: 28 Jan 95 17:56:36 GMT
Organization: Iowa State University, Ames, Iowa

In <3fvrel$[e-mail]> [e-mail] (Robert A. Uhl) writes:

>In article <[e-mail]>,
>Robert Mah <[e-mail]> wrote:
>>Creating a true random number generator using turing machines (i.e.
>>digital computers) is impossible.

>  Actually, it is possible if one hooks up certain op-amps in such a
>fashion as to generate a chaotic sequence. With the right feedback loops
>and A/D conversions, the numbers therefrom are as random as they get.
>Well, they _are_ chaotic, but it is close enough to random for
>_anything_ that you will be using it for.

Op amps are of course ANALOG devices, but anyway, what exact circuit or
type of circuit are you talking about? I've tried to think of one that
produces a chaotic waveform, but I haven't got any ideas yet.

--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
If you want peace, work for justice. If you want prosperity, work for
free markets, if you want to write Mac software, you're outta luck.

+++++++++++++++++++++++++++

>From [e-mail] (Dan Lakeland)
Date: 28 Jan 95 18:02:14 GMT
Organization: Iowa State University, Ames, Iowa


Is there an ANSI standard for the algorithm used in the ansi rand()
function? it's probably linear congruential as well, seems like everyone
uses that method.

What algorithm does Metrowerks use in their implementation of rand()??

thanks

--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
If you want peace, work for justice. If you want prosperity, work for
free markets, if you want to write Mac software, you're outta luck.

+++++++++++++++++++++++++++

>From [e-mail] (Bob Polis)
Date: Mon, 30 Jan 1995 12:18:02 GMT
Organization: Moret Ernst & Young

In article <[e-mail]>, [e-mail]
(Dan Lakeland) wrote:

> Op amps are of course ANALOG devices, but anyway, what exact circuit or
> type of circuit are you talking about? I've tried to think of one that
> produces a chaotic waveform, but I haven't got any ideas yet.

Ten years ago I built two hardware random generators to hook up to my old
Z80 computer. My main drive to do this was raw speed. Using hardware
enabled me to get random numbers some 40 times faster than using the OS's
random routine.

One was an analog white noise generator, which is a circuit used in old
analog music synthesizers. It usually depends on some physical behavior of
a 'misused' transistor. This transistor will then generate some chaotic
signal, which has to be amplified using an opamp. The resulting signal's
spectrum is uniformly distributed between some lowest and highest
frequency. Using this signal in a computer via an A/D-convertor will yield
random numbers. Of course, the problem with this type of circuit is, that
you cannot precisely determine the distibution, which is also somewhat
dependent on environmental circumstances.

The other was a hardware implementation of the well-known
shift-register-based generator. Since it would be clocked by some simple
clock circuit (not even using a crystal), it would have no relationship
with the computer's clock whatsoever. This circuit also has the
disadvantage that you cannot predict the distribution exactly, because of
possible nasty ratios between the generator's clock and that of your
computer.

All in all, these circuit are (also) far from perfect, but are very fast
(you need _one_ memory or I/O-read to obtain a random number), and well
suited for audio/music noise applications.

--
Bob Polis
[e-mail] (Changed since October 17, 1994!)
Moret Ernst & Young, The Netherlands

+++++++++++++++++++++++++++

>From [e-mail] (Brad Howes)
Date: 30 Jan 1995 16:21:17 GMT
Organization: Motorola Corporate Computer Services

In article <[e-mail]>, [e-mail] (Eric Traut) writes:

>>> How good is Random()?
ET> The Random() function implemented in QuickDraw does a pretty good job at
ET> random number generation. However, it has one flaw which prevents it from
ET> generating a good random distribution. The original author of Random()
ET> decided it would return numbers in the range -32767 to 32767. The algorithm
ET> used internally to generate pseudo-random numbers generates a 16-bit
ET> quantity. Since this quantity could be outside the specified range (i.e. it
ET> could be -32768), the routine was coded to simply return zero in this case.
ET> That means that Random() is twice as likely to return zero than any other
ET> number.

Also, I have seen code that attempts to limit the random number as follows:

   a = (unsigned long )Random() % MAX_VALUE_MINUS_1;
   // ...or even...
   a = (unsigned long )Random() & MAX_POWER_OF_2_VALUE_MINUS_1;

Unfortunately, for linear congruential generators, the above actions can
destroy the generator's long random sequence, and reveal non-random sequences
or cycles present in the low digits. See Sedgewick's _Algorithms in C_, pg 513
for bad/good examples.

Brad

--
+---------------------------------------------------------------------------+
| Brad Howes                       | Motorola E-Mail: XBH001                |
| Distributed Systems Applications | Internet: [e-mail]               |
| Motorola Corporate Computer Svcs |           [e-mail]         |
| Scottsdale, AZ                   | Voice: 602 441 1522  Fax: [phone] |
| USA                              | Pager: 800 SKY PAGE  PIN: 1254799      |
+---------------------------------------------------------------------------+


+++++++++++++++++++++++++++

>From [e-mail] (Robert A. Uhl)
Date: 30 Jan 1995 18:22:51 GMT
Organization: University of Denver

In article <[e-mail]>,
Dan Lakeland <[e-mail]> wrote:
>In <3fvrel$[e-mail]> [e-mail] (Robert A. Uhl) writes:
>
>Op amps are of course ANALOG devices, but anyway, what exact circuit or
>type of circuit are you talking about? I've tried to think of one that
>produces a chaotic waveform, but I haven't got any ideas yet.

  It's in an old issue of Scientific American. Don't have the month/year
on me right now, but it was The Amateur Scientist, discussing a chaotic
encryption method. Quite nice, actually.


--
- ------------------------------------------------------------------------
| Bob Uhl | Spectre                  | `In touto nika' +                 |
| U of D  | Baron Robert von Raetzin | http://mercury.cair.du.edu/~ruhl/ |
- ------------------------------------------------------------------------

---------------------------

>From [e-mail] (Nigel Higgins)
Subject: Tip Of the Month: Transparent PICTs
Date: Sun, 22 Jan 1995 00:53:44 GMT
Organization: The Education Technology Centre of British Columbia. (Canada)


A while back there was a discussion on how to draw PICTs onto the screen
so that any white areas of the PICT would become transparent and not
cover up things in the background.

There were many suggestions made, from using GWolrds and CopyMask, to
transparent modes, etc... but here is the simplest way I have found that
works. It requires no added source. You can draw the PICTs just like any
other PICTs.

All you need is a copy of the commercial version of Kid Pix (broderbund)
Take the PICt you wish to draw transparent, paste it into Kid Pix, select
it again and copy it. Then add it to your project resource fork. I have
no idea how it works or what Kid Pix does, but it works just fine. The
PICT will draw in your program just as always, but any white pixels will
become transparent.

Pretty cool eh?

+------------------------------------------------------------------------+
|Aaron Davidson        |I've told you a *million* times not to exagerate!|
|[e-mail]    |-------------------------------------------------+
|Silicon Creek Software|      Box 246, Kamloops BC, Canada, V2C 5K6      |
+------------------------------------------------------------------------+


+++++++++++++++++++++++++++

>From [e-mail] (Steve Fenwick)
Date: Fri, 27 Jan 1995 23:26:41 -0800
Organization: a2i network

In article <[e-mail]>, [e-mail]
(Nigel Higgins) wrote:

> A while back there was a discussion on how to draw PICTs onto the screen
> so that any white areas of the PICT would become transparent and not
> cover up things in the background.
>
[KidPict copy-paste-copy method]
>
> Pretty cool eh?

Yup. This also works with Studio/8, which also has some
other great features, like a floating palette with cursor
position reporting and click-drag box sizing, which is
very handy for finding the dimensions of a picture.

Steve

--
Steve Fenwick                                         [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Denis Birnie)
Date: Sun, 29 Jan 1995 09:37:53 +1200
Organization: Information Services, University of Canterbury

>> A while back there was a discussion on how to draw PICTs onto the screen
>> so that any white areas of the PICT would become transparent and not
>> cover up things in the background.
>
>This also works with Studio/8, which also has some
>other great features, like a floating palette with cursor
>position reporting and click-drag box sizing, which is
>very handy for finding the dimensions of a picture.
>
For finding the dimensions of a picture the new Scrapbook that comes with
System 7.5 is quite good - it displays the dimensions and (rsrc) size of
the images.  Sure beats counting pixels!

Denis
--
The above in no way reflects the opinion or standards of...
 - the University of Canterbury
 - the doctors who give me my medication
 - myself, five minutes from now, then, tomorrow or yesterday...
                              (depending on your timezone :-)
- --

---------------------------

>From [e-mail] (Dan Lakeland)
Subject: True RANDOM numbers, (was Re: Quality of Random())
Date: 19 Jan 95 18:54:12 GMT
Organization: Iowa State University, Ames, Iowa

As long as we're on the topic of random numbers, anyone have an idea for
a good electronic true-random-number dongle you could plug into the back
of your mac? Preferably non-radioactive...

for example, I've thought about tuning an AM reciever to some random
frequency, and reading the (scaled) voltage level w/ an 8 bit A/D
converter every few milliseconds.
--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
If you want peace, work for justice. If you want prosperity, work for
free markets, if you want to write Mac software, you're outta luck.

+++++++++++++++++++++++++++

>From [e-mail] (Ken Iwasa)
Date: 22 Jan 1995 03:57:55 GMT
Organization: University of Maryland, College Park

In article <[e-mail]>,
Dan Lakeland <[e-mail]> wrote:
>As long as we're on the topic of random numbers, anyone have an idea for
>a good electronic true-random-number dongle you could plug into the back
>of your mac? Preferably non-radioactive...
>
>for example, I've thought about tuning an AM reciever to some random
>frequency, and reading the (scaled) voltage level w/ an 8 bit A/D
>converter every few milliseconds.

But how would you pick this "random frequency"?  :)

>--
>Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
>If you want peace, work for justice. If you want prosperity, work for
>free markets, if you want to write Mac software, you're outta luck.

Ken

+++++++++++++++++++++++++++

>From [e-mail] (James Egelhof)
Date: Sun, 22 Jan 1995 18:25:35 -0500
Organization: Cloud 9 Internet * White Plains, NY USA

In article <3fsl43$[e-mail]>, [e-mail] (Ken
Iwasa) writes:
> >for example, I've thought about tuning an AM reciever to some random
> >frequency, and reading the (scaled) voltage level w/ an 8 bit A/
> >D converter every few milliseconds.
>
> But how would you pick this "random frequency"?  :)

Y'know, there's a point where the numbers are just so damned close to random
that we can call them random and nobody will care.


- -

 -----------------------------------------------------------------------
 James M. Egelhof       Finger for PGP Public Key |  [e-mail]
 Opinions are mine alone - not even my hamsters'. |   [e-mail]
 Welcome to the "Information Superhighway"...     |     [e-mail]
                     AOL users, stay to the right!|           james@home
 -----------------------------------------------------------------------


+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Mon, 23 Jan 1995 11:53:29 -0500
Organization: One Step Beyond

[e-mail] (James Egelhof) wrote:

) [e-mail] (Ken Iwasa) writes:
)
) > > for example, I've thought about tuning an AM reciever to some
) > > random frequency, and reading the (scaled) voltage level w/ an
) >
) > But how would you pick this "random frequency"?  :)
)
) Y'know, there's a point where the numbers are just so damned close
) to random that we can call them random and nobody will care.

Depends upon the application now, doesn't it?  For games, school
projects, small business models, rand() and Random() are probably
OK.  But if you're modeling air traffic control systems, nuclear
power plants, etc. -- well, I think you'd better look into other
algorithms.

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     [phone]
One Step Beyond         and Network Consulting           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lars Farm)
Date: Tue, 24 Jan 1995 14:32:31 +0100
Organization: Mid Sweden University

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:

> Depends upon the application now, doesn't it?  For games, school
> projects, small business models, rand() and Random() are probably
> OK.  But if you're modeling air traffic control systems, nuclear
> power plants, etc. -- well, I think you'd better look into other
> algorithms.

The toolbox Random() is Park and Millers "minimal standard" rng described
in CACM-10 1988, p1192-1201. "Random Number Generators: Good ones are hard
to find". You must use the rand seed for value not the Random() result.
The initial seed must be 1 <= seed < 2^31-1. Their claim is that it's
fast, small, has full period (produces all values between 1 and 2^31-1)
and is "random". Not knowing too much about random number generators, I'd
like to learn: In what way is this generator not good?

Lars

--
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Tue, 24 Jan 1995 14:05:03 -0500
Organization: One Step Beyond

[e-mail] (Lars Farm) wrote:

) [e-mail] (Robert Mah) wrote:
)
) > Depends upon the application now, doesn't it?  For games, school
) > projects, small business models, rand() and Random() are probably
) > OK.  But if you're modeling air traffic control systems, nuclear
) > power plants, etc. -- well, I think you'd better look into other
) > algorithms.
)
) The toolbox Random() is Park and Millers "minimal standard" rng
) described in CACM-10 1988, p1192-1201. "Random Number Generators: Good
) ones are hard to find".

I'm afraid I haven't read that paper.


) You must use the rand seed for value not the Random() result.  The
) initial seed must be 1 <= seed < 2^31-1. Their claim is that it's
) fast, small, has full period (produces all values between 1 and 2^31-1)
) and is "random". Not knowing too much about random number generators,
) I'd like to learn: In what way is this generator not good?

I always just assumed that Random() uses the Linear Congruential method.
If so, then no matter what the multiplier and increment are, it will
still have poor k-space distribution and the low order bits won't be as
random as the whole number.  See my other posts on this topic for more
details.

If it is a linear congruential generator, I don't see how using the seed
instead of the function's result (which is probably just the hi or low
word of the seed) would solve these problems.  On the other hand, maybe
they don't use a strait linear congruential method.  In that case, every-
thing above is sort of irrelivant (sp?).

Could you describe the algorithm they use in their paper?  Or is does
the paper mostly cover choosing "proper" values for the multiplier and
increment along with analysis of these choices?

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     [phone]
One Step Beyond         and Network Consulting           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jim Banner)
Date: Mon, 23 Jan 95 23:09:00 -0800
Organization: CES Internet Gateway

DL> As long as we're on the topic of random numbers, anyone have an idea for
DL> a good electronic true-random-number dongle you could plug into the back
DL> of your mac? Preferably non-radioactive...

Sentinel EvE hardware keys have built-in random number generators...




+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Wed, 25 Jan 1995 08:16:18 GMT
Organization: Adobe Systems Incorporated

In article <[e-mail]>, [e-mail]
(Dan Lakeland) wrote:
> As long as we're on the topic of random numbers, anyone have an idea for
> a good electronic true-random-number dongle you could plug into the back
> of your mac? Preferably non-radioactive...
>
> for example, I've thought about tuning an AM reciever to some random
> frequency, and reading the (scaled) voltage level w/ an 8 bit A/D
> converter every few milliseconds.

You might want to look into Johnson noise or and Shot noise. Johnson noise
occurs as a variation in voltage across a resistor. Shot noise is a
variation in current amplitude that occurs in any conductor. Both are the
direct result of basic physical phenomena, e.g. Shot noise results from
the discrete nature of electrons in a current flow. Both forms are white
(equal energy distribution across the spectrum) and have Gaussian
distribution on their "values." In other words, they are very high quality
random noise for a lot of purposes. The only problem is designing a
detector that can take advantage of these phenomena as the detector itself
will experience these types of noise. But there may be ways around that.
See _The _Art_Of_Electronics_ by Horowitz and Hill for an intro on this. I
suppose one could take advantage of metastable states in a flip-flop as
well, but I'm not sure about that.

Another possibility is to sample a very fast clock at a much lower
frequency which is not quite deterministic. This technique is used to
accomplish "random TLB" replacement in the MIPS R-Series microprocessors.
There is a "random" register which increments every clock cycle and wraps
around at the maximum TLB index. There is a TLB write random instructions
that replaces the TLB entry indexed by the random register. The random
register itself cannot be used to make a good random number generator of
course as the number of cycles in a loop reading that register would be
quite deterministic. Also, "random replacement" is implemented in certain
set-associative caches. The latest ARM chips use this I believe. (I do not
know the circuit details or how good the randomness is.)

(I've set the followup to sci.electronics as that seems a better place for
discussing electronic noise, the physical phenomena not the genre of music
of course. For info on random cache replacement circuitry, try comp.lsi.)

Zalman Stern               [e-mail]                 [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Bicycling, skating, and love all require falling with confidence and grace.

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 25 Jan 1995 10:29:46 +0100
Organization: The Conspiracy

In article <[e-mail]>,
[e-mail] (Robert Mah) wrote:

>) Y'know, there's a point where the numbers are just so damned close
>) to random that we can call them random and nobody will care.
>
>Depends upon the application now, doesn't it?  For games, school
>projects, small business models, rand() and Random() are probably
>OK.  But if you're modeling air traffic control systems, nuclear
>power plants, etc. -- well, I think you'd better look into other
>algorithms.

FM interstation noise is VEERY white, more so than AM noise.
And you can easily detect whether you have a carrier or not
with FM. The rest is left as an excercise for the EE types.

Cheers

                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"My pad of paper is not backlit."
     Greg King


+++++++++++++++++++++++++++

>From [e-mail] (Lars Farm)
Date: Thu, 26 Jan 1995 13:44:28 +0100
Organization: Mid Sweden University

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:

> I always just assumed that Random() uses the Linear Congruential method.

It does.

> If so, then no matter what the multiplier and increment are, it will
> still have poor k-space distribution and the low order bits won't be as
> random as the whole number.  See my other posts on this topic for more
> details.

I'll see if I can find your post. "k-space" where can I read up on that?
Knuth? Sedgewick doesn't mention "k-space". As for randomness of low order
bits, that's one of the things P&M talk about.

> If it is a linear congruential generator, I don't see how using the seed
> instead of the function's result (which is probably just the hi or low
> word of the seed) would solve these problems.

Uhm, I'm the one asking here;-) I'm no expert on random numbers. Just
trying to learn. Random() returns the low word of the actual result stored
in randseed giving diffrent distribution and shorter period than intended.

>  On the other hand, maybe
> they don't use a strait linear congruential method.  In that case, every-
> thing above is sort of irrelivant (sp?).
>
> Could you describe the algorithm they use in their paper?

It's a long time since I read the paper. The rng is a straight MLCG with
carefully choosen constants, giving good randomness and full period (every
value>0 representable in a long). If this really is good or bad I don't
know, that's why I asked.

>  Or is does
> the paper mostly cover choosing "proper" values for the multiplier and
> increment along with analysis of these choices?

Yes + choice of initial seed (sum: if the rng is ok it doesn't matter any
value in the sequence will do) + analysis of several common rngs (rand())
and their faults.

Lars

--
[e-mail]

+++++++++++++++++++++++++++

>From Scott Hutinger <[e-mail]>
Date: 27 Jan 1995 17:45:10 GMT
Organization: Macomb Projects

In article <[e-mail]> Lars Farm,
[e-mail] writes:
>Uhm, I'm the one asking here;-) I'm no expert on random numbers. Just
>trying to learn. Random() returns the low word of the actual result
stored
>in randseed giving diffrent distribution and shorter period than
intended.
>
>>  On the other hand, maybe
>> they don't use a strait linear congruential method.  In that case,
every-
>> thing above is sort of irrelivant (sp?).
>>
>> Could you describe the algorithm they use in their paper?
>
>It's a long time since I read the paper. The rng is a straight MLCG with
>carefully choosen constants, giving good randomness and full period
(every
>value>0 representable in a long). If this really is good or bad I don't
>know, that's why I asked.
>
>>  Or is does
>> the paper mostly cover choosing "proper" values for the multiplier and
>> increment along with analysis of these choices?
>
>Yes + choice of initial seed (sum: if the rng is ok it doesn't matter any
>value in the sequence will do) + analysis of several common rngs (rand())
>and their faults.

I am sure that the folks from Apple, do have quite a bit of stats on
Random(),  along with more information that would be useful everyone.
It's not like many of us have the time when wanting to use Random() to
check all seeding variations, then see whats best.  But, if we knew what
were best...

Possibly they could be of some help in this situation?

I must have had problems with my seeds, as I could look at the numbers
and notice stipes within them.  I realize the other problems I could
incorporate to give me poor distribution.

BTW k is just one of those terms some madman termed.

I think I should go look up the 1988 volume, as I don't have that
floating on my shelf.   Thats just one more good reason not to code today
:-)

[e-mail]
-- procrastinating finishing my code by reading newsgroups :-)

+++++++++++++++++++++++++++

>From [e-mail] (Eric Hegstrom)
Date: 27 Jan 1995 17:18:00 GMT
Organization: 3DO Company

In article <[e-mail]>
[e-mail] (James Egelhof) writes:

> > >for example, I've thought about tuning an AM reciever to some random
> > >frequency, and reading the (scaled) voltage level w/ an 8 bit A/
> > >D converter every few milliseconds.
> >
> > But how would you pick this "random frequency"?  :)

I once proposed a siliar idea but a few people pointed out to me that
because of man-made interference and lightning strikes etc., the
"static" wouldn't be truly random. I always liked the idea though.

-Eric

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This in no way represents the opinion of my employer
-- or anyone at all for that matter.

A very bright programmer -- I'm wearing flourescent underware.

+++++++++++++++++++++++++++

>From [e-mail] (David Clancy)
Date: 29 Jan 1995 11:23:39 GMT
Organization: University of California, Davis

Robert Mah ([e-mail]) wrote:

: Depends upon the application now, doesn't it?  For games, school
: projects, small business models, rand() and Random() are probably
: OK.  But if you're modeling air traffic control systems, nuclear
: power plants, etc. -- well, I think you'd better look into other
: algorithms.

: Cheers,
: Rob

And maybe other computers.  I've been modeling a nuclear power plant on my
LC for 3 years now...

--xav
Maybe I should give it the whole CPU, instead of letting the air traffic
control system simulation share time...


---------------------------

End of C.S.M.P. Digest
**********************